-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-72611] Forbid updating credentials ID for IdCredentials
#506
Conversation
@@ -325,6 +326,11 @@ private synchronized boolean updateCredentials(@NonNull Domain domain, @NonNull | |||
checkPermission(CredentialsProvider.UPDATE); | |||
Map<Domain, List<Credentials>> domainCredentialsMap = getDomainCredentialsMap(); | |||
if (domainCredentialsMap.containsKey(domain)) { | |||
if (current instanceof IdCredentials && replacement instanceof IdCredentials) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsure what makes more sense here AND or OR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
depends if we should be able to replace an IdCredential
with a non IdCredential
To me adding or removing an ID (replacing an IdCredential with a non IdCredential or vice versa) would sound like a change in the actual Id so OR
would make sense.
Any migration from a non IdCredential to IdCredential should occur seemlessly in data migration based on readResolve
generating a unique Id on load, and hence this method should not have to worry about that.
But I think either AND
or OR
is acceptable here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would like to have more opinions here. Maybe @jglick or @daniel-beck ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tentatively would prefer ||
for the same reasons as James argues for it.
(waiting for resolution of #506 (comment) before merging) |
@@ -35,15 +34,19 @@ | |||
/** | |||
* A test credentials impl. | |||
*/ | |||
public class DummyCredentials extends BaseCredentials implements UsernamePasswordCredentials { | |||
public class DummyCredentials extends BaseStandardCredentials implements UsernamePasswordCredentials { | |||
|
|||
private final String username; | |||
|
|||
private final Secret password; | |||
|
|||
@DataBoundConstructor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the old constructor remain the DataBoundConstructor
or should that move to the new one? Do we have UI tests that even use this? Should a null
ID be a problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have UI tests that even use this
there's a jelly file at least so at some point in time Stephen went to the effort of ensuring the UI at least worked...
<st:include page="id-and-description" class="${descriptor.clazz}"/>
Should a null ID be a problem?
Shouldn;t be as BaseStandardCredentials will generate a uniqueID if null
(so long as not one is expecting anything stable here!).
credentials-plugin/src/main/java/com/cloudbees/plugins/credentials/impl/BaseStandardCredentials.java
Lines 78 to 82 in 7eb51b3
public BaseStandardCredentials(@CheckForNull String id, @CheckForNull String description) { | |
super(); | |
this.id = IdCredentials.Helpers.fixEmptyId(id); | |
this.description = Util.fixNull(description); | |
} |
credentials-plugin/src/main/java/com/cloudbees/plugins/credentials/common/IdCredentials.java
Lines 94 to 96 in 7eb51b3
public static String fixEmptyId(@CheckForNull String id) { | |
return StringUtils.isEmpty(id) ? UUID.randomUUID().toString() : id; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just found out that https://github.com/jenkinsci/credentials-plugin/blob/master/src/test/java/com/cloudbees/plugins/credentials/impl/DummyIdCredentials.java exists. I'll revert the change here and only adapt affected tests to use DummyIdCredentials.java
@@ -457,4 +458,14 @@ public void credentialsSortedByNameInUI() { | |||
assertThat(options.get(0).value, is("2")); | |||
assertThat(options.get(1).value, is("1")); | |||
} | |||
|
|||
@Test | |||
@Issue("SECURITY-3252") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wrong reference?
@Issue("SECURITY-3252") | |
@Issue("JENKINS-72611") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, updated in eb2d6ca
|
Another attempt at https://issues.jenkins.io/browse/JENKINS-72611 as #502 caused regressions.
Testing done
Tested interactively, made sure that two credentials cannot have the same ID. Tested interactively with credentials that are not
IdCredentials
(used this).Submitter checklist